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EXECUTIVE  SUMMARY 


BACKGROUND 


The  recent  war  efforts  in  Kosovo  highlighted  specific  problems  with  recording,  reporting,  and 
transferring  reparable  spares  demand  data.  If  home  (transferred  from)  bases  don’t  properly 
record  failure  data  that  occurred  at  the  contingency  site,  worldwide  Readiness  Based  Levels 
(RBL)  could  be  skewed.  Properly  reported  failures  will  ensure  the  spares  available  will  be 
prioritized  and  properly  distributed.  Improper  recording  and  reporting  of  demand  data  can  effect 
the  accuracy  of  base  levels  and  the  worldwide  peacetime  operating  stock  (POS)  and  readiness 
spares  package  (RSP)  requirements.  During  Kosovo,  two  Major  Commands,  HQ  USAFE  and 
HQ  ACC,  were  recording  and  reporting  contingency  demand  data  differently.  Both  had  their 
own  locally  devised  programs  to  gather  the  data  for  transfer,  but  both  transferred  the  data  at 
different  times. 

PROBLEM  STATEMENT 


The  Air  Force  has  no  clear,  concise  procedure  for  reporting  and  recording  demand  data  at  the 

contingency  location  and  transferring  contingency  demand  data  to  the  home  base,  to  ensure 

proper  level  allocations  and  valid  worldwide  POS  and  RSP  requirements. 

STUDY  OBJECTIVES 

1 .  Determine  the  current  procedures  (both  formal  and  informal)  for  reporting  failure  data. 

2.  Define  what  procedures  are  needed  to  properly  record,  report  and  transfer  contingency 
demand  data. 

3.  Identify  shortfalls  between  current  procedures  and  desired  results. 

4.  Develop  system  requirements  -  how  to  achieve  desired  results. 

5.  Document  proposed  procedures  for  the  system. 

CONCLUSIONS 

1 .  There  is  no  standard  procedure  for  recording,  reporting,  and  transferring  contingency  demand 
data. 

2.  There  is  no  standard  program  to  collect  transferred  unit  data  and  update  home  base  records. 
The  ACCL73  currently  collects  demand  data  to  transfer. 

3.  There  is  no  supply  Transaction  Identification  Code  (TRIC)  to  accurately  update  the  Standard 
Reporting  Designator  (SRD)  consumption  records. 

4.  There  is  no  method  to  separate  peacetime  and  wartime  demands. 

5.  The  Air  Force  Wartime  Supply  Policy  Working  Group  approved  transferring  demand  data 
when  the  weapon  system  returns  to  their  home  base. 

6.  The  base  closure  flag  suits  the  need  better  than  maximum  levels  of  zero  for  suppressing 
contingency  levels. 
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RECOMMENDATIONS 


1.  Approve  and  post  our  proposed  procedures  (Appendix  A)  for  AFMAN  23-1 10,  Volume  2, 
Part  2,  Chapter  26,  Section  O,  Contingency  Demand  Data  Recording,  Reporting,  and 
Transferring  (Appendix  A).  The  proposed  procedures  are  based  upon  the  AFWSPG 
recommendations  and  the  ACC  L73  program.  (OPR:  USAF/ILSP) 

2.  As  an  interim,  post  the  ACC  L73  SURGE  program  on  a  web  site  along  with  the 
documentation  to  process  the  program  (OPR:  ACC/RSSM)  and  mandate  its  use 
(OPR:  USAF/ILSP). 

3.  Enhance  the  L73  to  (a)  produce  dynamic  files  based  upon  the  input  parameters  and  (b) 
produce  the  FCL/FRR  files  to  subtract  the  transferred  demands  from  the  contingency  site 
records  (Appendix  C).  (OPR:  ACC/RSSM) 

4.  Using  the  ACC  L73  as  a  guide,  develop  a  permanent  SBSS  program(s)  to  perform  the  same 
functions  with  our  proposed  enhancements.  (OPR:  USAF/ILSP  OCR:  SSG/ILS) 

5.  Develop  a  supply  TRIC  to  add/delete/update  the  SRD  consumption  records. 

(OPR:  USAF/ILSP  OCR:  SSG/ILS) 

6.  Modify  RBL  to  allocate  base  levels  separately  from  Contingency  High  Priority  Mission 
Support  Kit  (CHPMSK)  levels.  (OPR:  AFMC/LGI  and  AFLMA/LGS) 

7.  Upon  completion  of  the  contingency,  MAJCOMs  should  use  the  RBL  Central  Leveling 
Summary  (CLS)  to  identify  and  delete  any  levels  or  demand  changes  for  any  RBL  NSNs  at 
the  contingency  base  for  weapon  systems  that  are  no  longer  assigned  to  that  base. 

(OPR:  ACC,  USAFE,  and  PACAF) 

8.  Upon  elimination  of  a  CHPMSK  at  a  location  that  no  longer  supports  the  weapon  system,  use 
the  RBL  CLS  to  ensure  all  demand  and  levels  data  is  purged  from  the  SBSS  and  CLS  files. 
(OPR:  Air  Force  Requirements  Team  AFLMA/LGS  and  AFMC/LGI) 

9.  Implement  a  system  to  ensure  7WS  transactions  are  received  from  all  bases. 

(OPR:  AFMC/LGI  OCR:  SSG/ILS) 

10.  Develop  procedures  for  identifying  and  separately  recording  wartime  from  peacetime 
demands.  (OPR:  USAF/ILSP) 

1 1 .  Modify  the  SBSS  to  identify  a  stock  number  with  a  base  closure  flag  to  RBL  via  the  XCB 
transaction.  (OPR:  USAF/ILSP  OCR: SSG/ILS) 

12.  Modify  RBL  to  accept  the  (stock  number)  base  closure  flag  and  treat  it  as  a  maximum  level 
of  zero.  (OPR:  USAF/ILSP  OCR:  AFMC/LGI) 

13.  Modify  the  logic  for  manual  stock  number  deletion  during  FID  processing  to  include  deleting 
item  records  with  a  maximum  level  of  zero  detail  (type  detail  “E”). 

(OPR:  USAF/ILSP  OCR:  SSG/ILS) 
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CHAPTER  1 


INTRODUCTION 


BACKGROUND 


The  recent  war  efforts  in  Kosovo  highlighted  specific  problems  with  recording,  reporting,  and 
transferring  reparable  spares  demand  data.  If  home  (transferred  from)  bases  don’t  properly 
record  failure  data  that  occurs  at  the  contingency  site,  worldwide  Readiness  Based  Levels  (RBL) 
could  be  skewed.  The  location  of  the  failure  isn’t  important  to  the  D041  system,  but  it  is 
important  for  RBL  to  allocate  levels.  Properly  reported  failures  will  ensure  the  spares  available 
will  be  accurately  prioritized  for  repair  and  properly  distributed.  Problems  with  levels  allocation 
will  occur  if  levels  are  allowed  to  build  in  two  locations  using  the  same  demand  data  (e.g., 
contingency  site  and  transferred  data  at  the  home  base).  During  Kosovo,  two  Major  Commands, 
HQ  USAFE  and  HQ  ACC,  were  recording  and  reporting  contingency  demand  data  differently. 
Both  had  their  own  locally  devised  programs  to  gather  the  data  for  transfer,  but  both  transferred 
the  data  at  different  times. 

There  are  no  programs  or  procedures  in  AFMAN  23-1 10  to  describe  collecting  and  transferring 
reparable  demand  data  from  the  contingency  site  to  the  home  base.  The  only  reliable  method 
currently  available  is  a  locally  written  Supply  Users  Report  Generator  (SURGE)  program 
developed  by  Technical  Sergeant  Michael  Garris  at  the  ACC  Regional  Support  Squadron  (RSS), 
but  the  timing  for  transferring  the  data  is  still  an  issue.  The  absence  of  standard  reporting 
procedures  resulted  in  reporting  complications  during  deployment. 

For  example,  should  units  transfer  the  data  to  the  home  Stock  Record  Account  Number  (SRAN) 
after  the  contingency  ended,  or  when  the  aircraft  return?  The  home  bases  will  have  all  the  proper 
demand  data  updated  for  base  levels  -  but  if  the  aircraft  rotated  home  before  the  end  of  the 
contingency,  the  home  base’s  demands  did  not  include  the  demands  the  aircraft  experienced 
while  transferred  to  the  contingency  location. 

Headquarters  ACC  was  transferring  the  data  back  to  the  home  SRAN  when  the  units  returned 
from  the  contingency.  Their  program  took  all  the  item  record  demands  from  the  contingency  site 
and  placed  them  in  the  item  records  at  the  home  base.  The  repair  cycle  records  had  the  proper 
quarterly  numbers  updated  as  well  as  adding  the  contingency  Standard  Reporting  Designator 
(SRD)  totals  to  the  home  base  SRD  totals.  However,  this  could  result  in  duplicate  reporting  to 
D041  if  reporting  occurred  within  the  same  quarter  and  the  transfer  of  the  contingency  records 
weren’t  adjusted  before  the  quarterly  D28.  If  the  contingency  host  base  used  items  in  common 
with  the  gaining  (transferred)  unit,  it  is  possible  the  contingency  base  levels  are  inaccurate  if  the 
home  base’s  demand  data  was  deleted  at  the  contingency  site. 

Another  complication  arising  from  the  Kosovo  war  was  that  there  was  no  standard  demand  code 
used  by  all  contingency  units.  Some  units  used  a  non-recurring  demand  code  because  peacetime 
operating  stock  (POS)  levels  were  not  desired  at  the  contingency  site.  AFMAN  23-110,  Vol  2, 
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Part  2,  attachment  1 1 A-8  describes  the  non-recurring  demand  code  as  “anticipated  to  be 
nonrepetitive”,  which  is  correct  at  the  contingency  site  but  not  for  the  Air  Force  in  general. 
Recording  demands  as  non-recurring  will  preclude  those  failures  from  being  reported  to  RBL  for 
levels  allocation.  Non-recurring  demands  are  not  counted  as  demands  against  supply  so  the 
demands  are  not  accrued  on  the  item  record  nor  is  the  repair  cycle  data  maintained  on  the  repair 
cycle  record.  In  short,  the  failure  data  will  not  be  recorded  or  reported  to  RBL  or  to  D041  via  the 
quarterly  (7WS)  report.  However,  non-recurring  failures  are  reported  via  DAC  transactions  from 
the  SBSS  to  D041,  but  the  7WS  has  replaced  the  DAC  as  the  source  of  failure  data  to  D041. 

The  ACC/LG  recognized  the  many  questions  and  problems  that  occurred  with  the  Kosovo 
contingency  demand  data  and  tasked  the  AFLMA  to  develop  new  (standard)  procedures  for 
recording,  reporting,  and  transferring  contingency  demand  data. 

PROBLEM  STATEMENT 


The  Air  Force  has  no  clear,  concise  procedure  for  reporting  and  recording  demand  data  at  the 
contingency  location  and  transferring  contingency  demand  data  to  the  home  base,  to  ensure 
proper  level  allocations  and  valid  worldwide  (POS  and  RSP)  requirements. 

STUDY  OBJECTIVES 

1 .  Determine  the  current  procedures  (both  formal  and  informal)  for  reporting  failure  data. 

2.  Define  the  procedures  to  properly  record,  report  and  transfer  contingency  demand  data. 

3.  Identify  shortfalls  between  current  procedures  and  desired  results. 

4.  Develop  system  requirements  -  how  to  achieve  desired  results. 

5.  Document  proposed  procedures  for  the  system. 
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CHAPTER  2 


CURRENT  SYSTEM 


OVERVIEW 


In  this  chapter,  we  examined  AFMAN  23-1 10  to  determine  current  supply  procedures  for 
recording,  reporting,  and  transferring  reparable  spares  demand  data.  We  contacted  the 
MAJCOMs  to  determine  current  procedures  they  have  developed  (if  any)  for  recording, 
reporting,  and  transferring  demand  data.  In  the  third  section,  we  determined  what  the  system 
should  (must)  do. 


CURRENT  AIR  FORCE  PROCEDURES 


AFMAN  23-110,  Vol  2,  Part  2  describes  procedures  for  proper  recording  and  reporting  of 
reparable  spares  demand  data,  but  there  is  no  mention  of  differences  between  contingency  and 
home  base  processing.  Actually  there  is  no  mention  of  specific  contingency  processing  (as  it 
relates  to  reparable  demand  data)  or  transferring  of  contingency  demand  data  from  the  sites  to 
the  home  base. 

Proper  demand  data  is  necessary  for  requirements  computation  (D041),  proper  RBL  allocations 
(D035E),  and  accurate  Readiness  Spares  Package  (RSP)  computations.  All  three  processes  are 
crucial  to  the  Air  Force  war-fighting  effort.  Any  glitches  in  one  of  these  three  processes  -  D041, 
RBL,  or  RSP  computations  -  can  lead  to  ineffective  wartime  support  and  inaccurate  peace  and 
contingency  requirements.  To  accurately  define  a  contingency  demand  data  system,  we  need  to 
better  understand  the  current  demand  data  feeds  and  needs  -  failure  data  sent  to  the  D041  system, 
demand  rates  used  for  levels  allocation  (RBL),  and  demand  rates  used  for  RSP  computation. 

D041  Failure  Data 

The  D041  is  the  requirements  computation  part  of  a  larger  process  used  to  determine  which  base 
will  get  which  parts.  It  relies  on  reports  from  the  Standard  Base  Supply  System  (SBSS)  to  get 
failure  data  so  it  can  compute  requirements  accurately.  The  SBSS  reports  failure  and  usage  data 
via  a  daily  report,  the  D28  Recoverable  Assembly  Management  Processing  System  (RAMPS) 
report,  to  the  Air  Force  Materiel  Command  (AFMC)  systems  (see  Figure  1). 

The  SBSS  reports  failure  data  to  the  D041  system  with  two  SBSS  transaction  identification  codes 
(TRICs),  but  different  timing  (daily  and  quarterly).  The  DAC  transactions  report  (on  a  daily 
basis)  any  change  in  the  reparable  asset  condition  via  the  D28.  The  D041  also  collects  7WS 
transactions  from  the  SBSS  during  the  quarterly  run  of  the  D28.  The  7WS  contains  basically  the 
same  failure  data  for  recurring  demands  from  the  item  and  repair  cycle  record  as  the  daily  DACs, 
but  in  a  single  and  more  accurate  transaction.  The  7WS  is  the  primary  TRIC  of  the  SBSS-to- 
D041  reporting  because  it  is  a  single  snapshot  of  the  failure  for  the  previous  90  days.  In  the 
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event  the  7WS  doesn’t  arrive  or  is  corrupted,  the  D041  uses  the  accumulated  daily  DAC 
transactions  from  the  SBSS. 


Figure  1,  RBL  Systems  Interface 


There  is  a  real  danger  of  reporting  failures  twice  with  the  DAC  and  7WS  transactions  when  the 
contingency  unit  takes  the  applicable  demands  back  to  their  home  station  and  the  home  station 
reports  via  the  7WS  (at  end  of  quarter)  and  the  contingency  location  reports  the  same  failures  via 
the  DAC  (daily).  The  Air  Force  Logistics  Management  Agency  (AFLMA)  report  LS199810300, 
Comparison  of  Repair  Cycle  Item  Failure  Data  (7WS  Versus  DAC),  showed  the  7WS  was  more 
reliable  and  more  accurate  than  the  DAC.  The  AFLMA  report  also  recommended  the 
development  of  an  automated  system  to  ensure  7WS  images  are  received  from  all  bases  (this  will 
alleviate  the  fear  of  reporting  twice!).  The  report  further  recommended  a  system  change  to  add 
all  failure  data  to  the  7WS  (especially  recurring  failures  that  are  coded  as  non-recurring)  and 
using  the  7WS  as  the  source  for  failure  data  for  the  D041  worldwide  requirements  computation. 

Unfortunately,  many  Kosovo  part  requests  were  recorded  as  non-recurring  and  the  subsequent 
demand/usage  data  was  not  reported  properly  on  the  7WS  from  the  contingency  sites.  The 
USAFE-modified  ACCL73  picked  up  all  non-recurring  demands  and  loaded  the  demand  data  at 
the  home  base  as  recurring  for  proper  quarterly  reporting  via  the  7WS,  but  this  only  works  if  the 
data  is  transferred  before  the  end  of  each  quarter.  Using  a  recurring  demand  code  is  cmcial  to 
collecting  and  reporting  valid  demand  data  to  the  D041  system. 

RBL  Usage  Data 

Another  crucial  factor  for  demand  data  reporting  is  proper  level  allocations  from  RBL.  RBL 
takes  the  D041  requirement  and  allocates  the  worldwide  requirement  to  each  using  base  to 
minimize  worldwide  expected  backorders  (EBO).  The  allocation  of  levels  relies  on  properly 
recorded  demands  (recurring  demand)  and  proper  SBSS  D28  reporting  to  the  AFMC  systems 
(via  an  XCB  transaction). 
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Levels  allocation  is  based  upon  the  daily  demand  rates  reported  to  RBL  (D035E)  via  the  XCB 
transaction  from  the  SBSS  (see  Figure  1).  The  XCB  is  generated  every  time  the  SBSS  performs 
file  status  on  a  reparable  National  Stock  Number  (NSN).  File  status  will  be  performed  on  all 
NSNs  at  least  once  a  quarter  giving  RBL  a  picture  of  each  reparable  NSN’s  demand  rates  for  the 
quarterly  levels  computation.  In  the  event  RBL  doesn’t  have  a  current  XCB  for  a  SRAN,  it  will 
send  an  XCD  to  the  base.  When  the  XCD  processes  in  the  SBSS  it  automatically  generates  an 
XCB  for  RBL. 

The  SBSS  computes  the  daily  demand  rate  using  all  recurring  demands.  Some  units  did  not  want 
RBL  levels  at  the  contingency  site  and  therefore  used  non-recurring  demand.  This  skews 
worldwide  requirements  data,  so  some  other  method  must  be  used  to  prevent  unneeded  RBL 
levels. 

Wartime  Requirements  (RSP)  Failure  Data 

Recorded  demand  data  is  critical  to  proper  RSP  computations.  The  Air  Force  uses  the  SBSS 
demand  data  to  review  worldwide  demand  rates  and  if  appropriate,  use  the  base  rates  to  compute 
RSP.  Theoretically,  the  best  source  of  contingency  failure  data  is  failure  data  collected  during  an 
actual  contingency.  Since  RSPs  are  computed  by  weapon  system,  the  SRD  consumption  records 
are  used  for  the  review.  Again,  as  long  as  each  base  records  the  data  correctly  (proper  demand 
code,  SRD,  etc.)  the  RSP  calculation  will  be  as  accurate  as  possible  for  that  base. 

The  RSP  computations  are  based  upon  the  demand  rates  stored  on  the  SRD  consumption  records. 
The  consumption  records  are  updated  when  the  Daily  SRD  Update  (D13)  is  processed  by  the 
SBSS.  Specific  transactions  are  selected  (AFMAN  23-1 10,  Vol  2,  Part  2,  Attachment  5B-13) 
and  the  demands  are  updated  according  to  the  NSN  and  SRD  of  the  selected  transaction.  There 
has  been  much  discussion  about  the  accuracy  of  the  SRD  consumption  records.  When  a 
transaction  is  processed  for  an  SRD  that  is  loaded,  but  invalid  for  the  specific  NSN  of  the 
transaction,  the  updates  are  still  applied  to  the  NSN/SRD  combination  of  the  transaction.  For 
instance,  NSN  1  is  processed  for  SRD  ABA  even  though  the  proper  SRD  is  AB1.  The  D13  will 
store  the  demands  against  NSN  1/ABA  on  the  SBSS  and  RSP  computations  will  be  based  upon 
this  data  even  though  the  correct  SRD  is  AB 1  -  this  is  why  using  the  correct  SRD  on  every 
transaction  is  absolutely  essential.  Problems  with  the  A01,  SRD  Update  program  are  discussed 
in  the  next  chapter. 

The  Air  Force  needs  accurate  data  on  which  to  compute  base  levels  and  peacetime  and  wartime 
spares  requirements.  It  begins  with  recording  the  data  accurately  and  in  a  timely  manner. 

“Wartime”  Versus  “Peacetime”  Demands 

The  SBSS  has  no  method  or  procedures  to  identify  and  separately  store  wartime  (contingency) 
data  from  peacetime  data.  The  Air  Force  records  all  demands  the  same.  In  essence,  the  Air 
Force  contaminates  the  failure  data  by  not  segregating  the  wartime  demands.  By  segregating  the 
data,  the  Air  Force  can  use  wartime  failures  to  forecast  wartime  requirements.  Further,  the  Air 
Force  will  not  inflate  peacetime  consumption,  and  therefore  peacetime  requirements,  for  items 
used  more  heavily  in  wartime  sorties. 
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The  Air  Force  needs  a  method  to  identify  and  separately  store  wartime  and  peacetime  demand 
data  for  accurate  peacetime  levels  and  wartime  forecasts.  We  discuss  options  to  identify  and 
store  wartime  and  peacetime  data  in  the  next  chapter. 


CURRENT  MAJCOM  PROCEDURES 


A  couple  of  similarities  exist  between  all  bases  that  currently  transfer  to  contingency  sites.  They 
all  transfer  with  their  RSP  and  possibly  a  Contingency  High  Priority  Mission  Support  Kit 
(CHPMSK  -  see  AFMAN  23-1 10,  Vol  1,  Part  1,  Chapter  14,  Section  E  for  CHPMSK 
guidelines).  However,  there  are  key  differences  as  noted  in  Table  2-1  below. 


Normal  Contingency  Actions 

Kosovo  Actions 

Max  levels  zero 

Yes* 

No* 

DAC 

From  contingency  location 

From  contingency  location 

7WS 

From  home  base 

From  contingency  location 

L73 

Yes,  when  unit  transfers  home 

Yes,  when  contingency  is  over 

Demands 

Recurring 

Non-recurring  ** 

Table  2-1,  Contingency  Processing  Differences 


*Yes  when  the  transferring  unit  falls  into  a  base  with  different  weapon  systems.  No  when  the 
transferring  unit  falls  into  a  base  with  the  same  weapon  systems. 

**  It  is  not  standard  practice  to  use  non-recurring  demand  codes,  yet  many  units  from  all 
MAJCOMs  that  deployed  for  Kosovo  chose  to  use  non-recurring.  There  is  currently  no  Air 
Force  policy  dictating  demand  code  usage  during  contingencies. 

As  Table  2-1  shows,  the  main  differences  are  whether  to  have  base  POS  levels  at  the  contingency 
site  and  when  to  transfer  the  demand  data.  The  differences  can  have  an  impact  on  RBL 
allocations  and  thus  the  ability  to  get  the  needed  parts  to  complete  the  mission.  Before  we 
discuss  differences,  we  need  to  discuss  demand  codes. 

Non-Recurring  Demand 

Some  units  recorded  demands  as  non-recurring.  As  discussed  earlier,  this  will  keep  the  reparable 
asset  demands  from  being  recorded  in  the  SBSS  and  keep  RBL  from  allocating  to  the  location  — 
impairing  the  ability  to  get  the  part  to  complete  the  mission.  The  failure  will  still  be  reported  to 
D041  via  the  DAC.  Contingency  demands  for  items  that  will  be  needed  again  to  support  the 
weapon  system  (that  will  recur)  must  not  be  coded  as  non-recurring  just  because  the  weapon 
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system  is  deployed.  The  base  must  use  the  recurring  demand  code  and  find  a  different  method 
(max  level  of  zero)  if  it  wants  to  prevent  the  establishment  of  base  levels  at  the  contingency  site. 

Base  POS  Levels 

We  propose  using  a  maximum  level  of  zero  to  prevent  the  contingency  SBSS  from  having  POS 
(RBL  or  repair  cycle  demand  levels).  There  could  be  many  reasons  for  wanting  to  suppress  base 
POS  levels  at  a  location  (e.g.,  political,  storage,  security),  but  the  method  should  be  simple, 
standard,  and  effective.  Some  units  loaded  a  maximum  level  of  zero  against  certain  stock 
numbers  to  prevent  the  establishment  of  a  level  for  that  stock  number.  This  method  must  be 
loaded  to  every  NSN  that  must  have  levels  suppressed.  Maximum  levels  of  zero  essentially  tells 
RBL  to  allocate  the  parts  elsewhere  because  the  base  has  no  need  for  any,  even  though  demand 
data  has  accrued  (before  or  during  the  transfer).  We  discuss  level  suppression  more  deeply  in 
chapter  3. 

When  to  Transfer  Data 

Some  units  transferred  the  demand  data  after  the  contingency,  while  others  upon  return  of  the 
unit  to  its  home  base.  This  could  result  in  lost,  misrouted,  or  duplicate  demand  data.  When  the 
timing  is  based  upon  the  command  of  the  deployed  unit  or  the  command  of  the  contingency 
personnel,  the  potential  for  lost  data  files  only  increases.  The  demand  data  should  be  reported 
where  the  weapon  systems  are  and  where  the  levels  are  needed. 

Collecting  the  Data  to  Transfer 

What  actions  are  taken  upon  unit  return?  Under  the  current  SBSS  procedures,  there  are  no 
standard  procedures  for  transferring  the  demand  data  back  to  the  home  base.  ACC  has  developed 
a  local  SURGE,  the  ACC  L73,  to  transfer  the  contingency  demand  data.  All  MAJCOMs  use  the 
L73  because  it  is  the  only  program  available  to  move  demand  data  from  contingency  sites  to  the 
home  base.  The  L73  builds  files  to  move  item  record  demand  data,  repair  cycle  data,  and  SRD 
consumption  data  to  the  home  base. 


ACC  L73  PROGRAM 


The  ACC  L73  is  a  SURGE  program  that  collects  the  demands  from  the  contingency  site, 
separates  the  data  for  transfer  to  the  home  base,  and  provides  SBSS  TRICs  that  generate  updates 
to  RBL.  It  pulls  data  from  the  contingency  database  using  specific  input  parameters  for  each 
unit.  Using  the  deployment  start/end  dates,  the  SRD,  the  system  designator  and  the  organization 
code  at  the  deployed  sites  -  the  L73  will  build  several  files  to  transfer  data  to  the  home  base. 

The  first  two  files  are  the  FCL  and  FRR  images  to  update  the  item  record  demand  data  and  repair 
cycle  records  respectively.  These  images  are  built  by  scanning  the  Consolidated  Transaction 
History  (CTH)  records  at  the  contingency  site.  Using  the  parameters  discussed  above,  all 
transactions  that  update  item  record  demands  and  the  repair  cycle  record  are  located  and  totaled. 
Note  the  program  can  and  does  collect  non-recurring  demands  as  well  as  recurring  demands.  The 
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L73  produces  a  single  image  for  each  NSN  per  TRIC.  The  images  must  be  processed  at  the 
home  base  SBSS  to  update  home  base  records  (Appendix  A).  In  order  to  complete  the  process, 
the  same  files  (FRR  and  FCL)  must  be  reformatted  to  subtract  the  demands  being  transferred 
from  the  records  at  the  contingency  site.  We  recommend  enhancing  the  L73  to  produce  these 
additional  FRR  and  FCL  files. 

The  next  file  (XCD  file)  prompts  the  SBSS  to  update  RBL  with  the  asset  usage  data  to  ensure 
proper  levels  allocation.  The  program  creates  XCDs  for  each  NSN  that  has  had  a  change  in  its 
demand  data.  The  XCD  image  is  a  daily  demand  rate  (DDR)  confirmation  request  and  it 
generates  a  report  of  the  most  recent  data  to  RBL  for  levels  computation.  By  processing  the 
XCDs  generated  by  the  L73,  the  host  account  saves  2-3  days  of  processing  time  because  they 
don’t  have  to  run  file  status  to  generate  the  reports  for  all  of  the  reparable  NSNs. 

The  final  file  generated  is  for  SRD  consumption  record  updates.  The  L73  reads  the  home  base 
records  and  compares  them  with  the  contingency  site  totals  to  build  a  file  of  new,  summed  totals 
by  NSN  -  the  home  base  data  is  not  overlaid  with  the  contingency  data.  By  adding  the 
contingency  totals  to  the  home  base  numbers  we  get  a  more  accurate  picture  of  specific  NSNs 
required  during  wartime  operations. 

There  is  a  slight  drawback  to  processing  the  SRD  file  with  the  L73.  Since  there  is  no  available 
supply  TRIC  to  apply  the  changes  to  the  database,  the  home  base  remote  processing  station 
(RPS)  must  have  access  to  Query  Language  Processing  (QLP)/Update  to  complete  the  SRD 
updates.  It  usually  requires  MAJCOM  permission  to  use  QLP/Update  because  it  is  a  controlled 
“file  alteration”  program.  The  changes  applied  to  the  SRD  records  allow  the  bases  the  most 
accurate  picture  possible  for  RSP  computations. 

Another  drawback  to  the  L73  is  only  one  organization  and/or  SRD  combination  can  be  used  at  a 
time.  If  multiple  SRDs  or  organizations  are  used  during  the  contingency  then  the  L73  must  be 
processed  multiple  times.  We  recommend  enhancing  the  L73  to  create  unique  files  based  upon 
the  input  parameters  (see  Appendix  C  for  sample  code). 

A  copy  of  all  files  used  for  demand  data  transfers  should  be  transmitted  to  the  MAJCOM  hosting 
the  contingency.  The  MAJCOMs  will  furnish  the  demand  data  files  to  the  AFLMA 
(Requirements  Team)  each  time  there  is  a  CHPMSK  review/validation. 

The  transferred  demand  data  files  are  the  only  (and  best!)  source  of  wartime  data.  Ideally,  a 
specific  agency  or  group  should  be  appointed  by  HQ  USAF/ILS  to  collect  and  maintain  all 
wartime  data.  The  AFLMA  has  been  the  data  collector/warehouser  for  the  last  two  major 
contingencies  and  should  maintain  this  role. 


WHAT  THE  SYSTEM  SHOULD  DO 


We  have  explained  the  current  procedures  the  Air  Force  uses  to  compute  levels  and  RSPs.  We 
also  pointed  out  the  different  types  of  failure  data  and  the  effect  failure  data  has  on  Air  Force 
systems.  Finally,  we  discussed  local  procedures  used  by  two  MAJCOMs  (ACC  and  USAFE)  to 
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transfer  data  to  home  bases.  Now  we  need  to  determine  what  a  contingency  demand  data  system 

should  do. 

1.  A  contingency  demand  data  system  should  use  a  standard  set  of  procedures.  The  procedures 
should  include  accurate  data  feeds  to  the  Air  Force  requirements  systems.  There  are  three 
purposes  for  accurately  collecting  and  reporting  contingency  data: 

Levels  Allocation-  demand  data  must  be  maintained  at  the  location  which  needs  POS 
(RBL)  levels.  If  the  weapon  systems  are  located  at  the  contingency  site,  then  the 
demands  are  initially  recorded  and  reported  from  the  contingency  site.  However,  a 
decision  must  be  made  as  to  which  POS  levels  are  needed  at  contingency  sites.  There 
must  be  the  capability  to  handle  the  exceptions  when  base  POS  levels  are  not 
required  at  the  contingency  site.  For  example,  ACC  units  deploying  to  Saudi  Arabia 
were  not  allowed  “permanent”  levels.  In  Southwest  Asia,  ACC  used  RSPs  and 
CHPMSKs  with  no  base  POS  level  (RBL,  RCDL,  or  ASL)  and  they  loaded  maximum 
levels  of  zero  at  their  contingency  sites.  USAFE,  on  the  other  hand,  had  units  transfer  in 
to  bases  with  like  weapon  systems  loaded  and  an  RBL  level  already  loaded.  In  those 
cases,  the  transferred  unit  could  use  its  RSP  and  CHPMSK  for  support,  but  the 
contingency  site  home  unit  still  needed  its  POS  level.  One  added  complication,  the 
contingency  unit  that  transferred  to  the  USAFE  base  will  record  failures  (satisfied  from 
the  CHPMSK),  but  those  failures  should  not  be  counted  for  the  contingency  home  unit’s 
levels  even  though  they  are  reported  at  that  location. 

POS  Requirements  -  The  Air  Force  requirements  computation  system  (D041)  needs 
failure  data  to  accurately  compute  requirements.  A  recurring  failure  is  one  that  is  likely 
to  recur.  Failures  caused  by  unusual  events  (aircraft  mishaps)  and  certain  repair 
(materiel/quality  deficiency  report)  actions  are  non-recurring.  Note  transient  aircraft  part 
failures  are  really  recurring  from  an  Air  Force  level  view  even  though  bases  are  instructed 
to  use  a  non-recurring  demand  code  because  the  items  shouldn’t  normally  be  stocked  at 
the  contingency  site.  D041  needs  all  failures  reported  and  must  make  a  distinction 
between  recurring,  recurring  non-recurring  (i.e.,  transient  aircraft)  and  non-recurring 
failures.  Currently,  the  SBSS  sends  only  recurring  failure  data  to  D041  quarterly  (at  the 
end  of  the  quarter)  via  the  7WS  transaction.  In  the  event  AFMC  does  not  receive  the 
7WS  from  a  base,  D041  uses  DAC  transactions  which  report  both  recurring  and  non¬ 
recurring  failures  daily  (as  failures  occur).  D041  uses  summed  failure  data  (the  overall 
total  from  all  SRANs)  -  it  does  not  need  failures  identified  to  the  SRAN  level.  The  7WS 
must  report  all  “recurring”  demands  to  D041.  It  doesn’t  matter  whether  the  contingency 
site  or  the  home  base  reports  the  data  as  long  as  they  don’t  duplicate  the  data.  Note  if  a 
unit  returns  to  home  base  and  transfers  its  contingency  data  to  the  home  base  (as  ACC  is 
doing),  then  the  sum  of  a  SRAN’s  DACs  will  not  equal  the  7WS  failures.  The  DACs 
would  have  been  reported  from  the  contingency  site  and  the  7WS  from  the  home  station. 
This  points  out  the  need  for  the  D041  to  use  the  7WS  and  for  AFMC  to  ensure  it  receives 
all  the  7WS  images  from  the  bases.  Using  DACs  from  one  base  and  7WS  for  another 
could  duplicate  demand  data. 
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RSP  Requirements  -  Annually,  the  Air  Force  computes  RSP  requirements  and  attempts 
to  use  failure  rates  that  most  accurately  reflect  contingency  operations  by  weapon  system 
by  squadron.  Theoretically,  contingency  demand  data  would  be  the  best  source  of  failure 
to  forecast  wartime  requirements.  So  a  contingency  demand  data  collection  system 
should  record  and  maintain  demand  data  by  weapon  system  (i.e.,  accurate  SRD 
consumption  records)  and  the  Air  Force  should  segregate  actual  contingency 
demand  data  separately  from  peacetime  SRD  data. 


2.  The  system  should  be  able  to  prevent  establishing  base  POS  levels,  but  must  record  demand 
data  for  transfer  to  the  home  station. 

3.  The  system  should  facilitate  the  deletion  of  stock  number  records  (adjusted  levels  and  item 
records)  automatically  at  the  end  of  the  contingency  (file  status  and  item  record  deletion 
criteria). 

4.  A  contingency  demand  data  system  must  be  automated  and  simple  to  use.  The  major 
concerns  are  the  ease  of  procedures  to  prevent  base  levels,  transfer  demand  data,  allocate 
proper  levels,  and  clean  up  contingency  records.  Contingencies  are  not  the  time  for  an 
increase  in  the  workload. 

5.  The  are  some  specific  issues  with  “wartime”  versus  “peacetime”  rates.  Should  the  base  load 
contingency  rates  (wartime)  onto  home  base  (peacetime)  item  and  repair  cycle?  Should  the 
base  report  contingency  demand  data  unfiltered  to  D041?  There  could  be  some  climatic  or 
operational  tempo  differences  to  consider.  The  Air  Force  should  have  the  ability  to  adjust 
base  and  wholesale  contingency  failure  data.  The  Air  Force  should  also  have  a  method  to 
segregate  wartime  from  peacetime  demand  rates. 

6.  Store  all  wartime  data  for  specific  wartime  computations  and  use  peacetime  data  for 
peacetime  levels  allocations.  Separate  accumulators  on  the  SBSS  for  wartime  and  peacetime 
data  would  provide  the  flexibility  needed  to  store  all  data  in  the  same  system  for  both 
wartime  and  peacetime  calculations. 
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CHAPTER  3 


SYSTEM  REQUIREMENTS 

PROPOSED  REQUIREMENTS 

Identify  contingency  data  by  SRD  and/or  organization  code 

An  accurate  contingency  demand  recording  and  reporting  system  should  identify  the  contingency 
data  by  SRD  and/or  organization  code  at  the  contingency  site.  It  should  then  transfer  (delete) 
item  record,  repair  cycle  and  mission  change  data  from  the  contingency  site  and  load,  change  or 
delete  the  data  (as  appropriate)  at  the  home  base.  The  SBSS  has  two  standard  TRICs  capable  of 
performing  these  changes  to  the  item  and  repair  cycle  records  -  the  FCL  and  the  FRR 
respectively.  The  system  would  have  to  automatically  generate  these  TRICs  to  transfer 
contingency  demand  data. 

Retrieve  contingency  SRD  consumption  data  by  NSN/SRD  and  add  it  to  home  base  data 

Another  requirement  is  to  retrieve  contingency  SRD  consumption  data  by  NSN/SRD  and  add  it 
to  home  base  SRD  data.  There  is  no  current  TRIC  to  perform  this  process.  There  is  an  SBSS 
report,  the  A01  SRD  File  Update  that  will  transfer  the  data.  However,  the  A01  does  not  meet  our 
needs;  it  does  not  add  the  demand  data  to  the  specific  NSN  records.  Instead,  the  A01  loads  the 
SRD  demand  data  across  an  SRD  to  all  NSNs  equally  at  the  home  base.  An  example  of  this  is 
found  in  Table  3-1 . 

Table  3-1  provides  an  example  of  a  home  base  with  15  NSNs  (prior  to  any  updates)  for  a  single 
SRD  and  a  contingency  site  with  45  total  demands  across  10  different  NSNs  for  the  same  SRD. 
Processing  the  A01  would  average  the  45  demands  over  all  NSNs  at  the  home  base  with  the  same 
SRD  (far  right  column  of  Table  3-1)  and  all  15  NSNs  would  gain  demands  on  each  NSN  -  even 
the  NSNs  with  no  demands  accrued  during  the  contingency  (column  3  of  Table  3-1  shows  the 
desired  effect  of  SRD  consumption  record  updates).  By  comparing  the  derived  totals  of  the 
desired  effect  and  the  A01  effect,  you  can  see  the  difference  in  the  demand  data  that  would  be 
used  to  compute  RSP.  NSN  5  had  no  demands  at  the  home  base  and  none  during  the 
contingency,  but  would  receive  3  demands  from  the  A01  and  would  probably  have  assets  in  the 
next  RSP  computation.  On  the  other  hand,  NSN  7  was  the  leading  requirement  during  the 
contingency  and  would  definitely  be  stocked  if  all  demands  were  applied  to  that  NSN  (desired 
effect).  However,  the  A01  would  average  the  demands  and  make  this  NSN  demand  data  much 
smaller  than  actual  consumption.  The  Air  Force  needs  a  better  method  to  load  contingency 
demand  data  by  NSN  to  the  home  base  SRD  record  than  the  current  A01  process. 
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Home  Base 
(before  updates) 

Contingency  Site 
(actual  demands) 

Home  Base 
(desired  effects) 

Home  Base 
(after  the  A01) 

NSN1  (1  dmd) 

NSN1  (8  dmds) 

NSN1  (1+8=  9  dmds) 

NSN1  (1+3=  4  dmds) 

NSN2  (2  dmds) 

NSN2  (5  dmds) 

NSN2  (2+5=  7  dmds) 

NSN2  (2+3=  5  dmds) 

NSN3  (2  dmds) 

NSN3  (2  dmds) 

NSN3  (2+3=  5  dmds) 

NSN4  (1  dmd) 

NSN4  (4  dmds) 

NSN4  (1+4=  5  dmds) 

NSN4  (1+3=  4  dmds) 

NSN5  (0  dmds) 

NSN5  (0  dmds) 

NSN5  (0+3=  3  dmds) 

NSN6  (3  dmds) 

NSN6  (3  dmds) 

NSN6  (3+3=  6  dmds) 

NSN7  (2  dmds) 

NSN7  (9  dmds) 

NSN7  (2+9=  11  dmds) 

NSN7  (2+3=  5  dmds) 

NSN8  (1  dmd) 

NSN8  (1  dmd) 

NSN8  (1+1=  2  dmds) 

NSN8  (1+3=  4  dmds) 

NSN9  (3  dmds) 

NSN9  (6  dmds) 

NSN9  (3+6=  9  dmds) 

NSN9  (3+3=  6  dmds) 

NSN10  (2  dmds) 

NSN10  (2  dmds) 

NSN10  (2+2=  4  dmds) 

NSN10  (2+3=  5  dmds) 

NSN11  (1  dmd) 

NSN11  (3  dmds) 

NSN11  (1+3=  4  dmds) 

NSN11  (1+3=  4  dmds) 

NSN12  (5  dmds) 

NSN12  (5  dmds) 

NSN12  (5+3=  8  dmds) 

NSN13  (4  dmds) 

NSN13  (4  dmds) 

NSN  13  (4+3=  7  dmds) 

NSN14  (0  dmds) 

NSN14  (2  dmds) 

NSN14  (0+2=  2  dmds) 

NSN14  (0+3=  3  dmds) 

NSN15  (1  dmd) 

NSN15  (5  dmds) 

NSN15  (1+5=  6  dmds) 

NSN15  (1+3=  4  dmds) 

15  NSNs  prior  to 
updating  with 
contingency 
demand  data 

10  NSNs  with  45 
total  demands 

Each  specific  NSN 
within  an  SRD  summed 
by  NSN  (add 
contingency  demands) 

45  demands  averaged 
over  ALL  15  NSNs 
within  the  SRD 
(add  3  to  each  NSN) 

Table  3-1,  Adding  Contingency  SRD  Demands  to  Home  Base  NSNs 


Use  a  standard  method  of  suppressing  POS  levels  at  contingency  sites 

An  accurate  system  should  use  a  standard  method  of  suppressing/limiting  POS  levels  at 
contingency  sites  when  applicable.  Note  base  POS  (RBL)  levels  are  required  if  the  contingency 
base  supports  the  same  weapon  system  (or  uses  common  items)  as  the  unit  transferring  to  that 
base.  So  preventing  base  levels  only  applies  to  different  weapon  systems  and  non-common 
items.  However,  we  may  need  to  limit  POS  levels  (not  just  transferred  unit’s  levels).  We  also 
need  to  determine  the  impact  that  any  POS  level  suppression  method  has  on  D041  and  RBL  for 
host  base  and  contingency  site  support. 

Base  Closure  Flag  -  Some  units  discussed  using  the  base  closure  flag  to  prevent  levels  allocation. 
It  meets  the  needs  of  the  contingency  base  because  it  is  easy  to  load  and  remove  and  it  works  for 
all  assets  whether  they  are  reparable  (RBL)  or  consumable.  The  base  closure  flag  prevents  the 
SBSS  from  requisitioning  for  POS  levels,  but  it  will  still  requisition  for  any  special  levels  and/or 
due-out  requirements.  Although  the  base  closure  flag  works  well  for  consumable  assets,  it 
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has  a  negative  impact  on  RBL.  RBL  will  still  allocate  the  level  to  the  contingency  SBSS 
NSNs,  but  the  SBSS  will  ignore  the  level  and  will  not  report  the  lost  level(s)  to  RBL. 
Unfortunately,  RBL  doesn’t  reallocate  the  level(s)  originally  allocated  to  the  contingency  SBSS 
NSNs  with  the  base  closure  flag  -  those  allocations  are  lost  for  the  entire  quarter. 

Maximum  Level  of  Zero  -  The  preferred  method  of  suppressing  levels  is  the  use  of  maximum 
level  of  zero  details,  primarily  because  it  works  well  with  RBL.  RBL  will  not  allocate  a  positive 
level  to  a  base  with  a  maximum  level  of  zero.  A  maximum  level  of  zero  works  well  with  all 
assets  (reparable  and  consumable)  and  it  meets  the  need  of  the  contingency  base.  It  is  a  little 
more  difficult  to  clean  up  at  the  end  of  the  contingency  because  item  records  with  max  levels  are 
not  automatically  deleted  via  file  status  processing  or  item  record  deletion. 

Short  Term  Solution  -  Load  the  base  closure  flag  to  all  contingency  stock  numbers  (reparable 
and  consumable)  that  are  new  record  loads  to  the  contingency  host  base  (different  weapon  system 
than  the  contingency  host  site)  and  do  not  require  a  base  POS  level.  However,  load  the 
maximum  level  zero  details  to  only  the  RBL  (reparable)  assets  as  well.  This  is  the  only  solution 
that  does  not  require  a  system  (RBL  and/or  SBSS)  change.  It  does  require  some  additional  base 
workload  (to  load  and  delete  the  maximum  level).  Although  not  a  short-term  solution,  we 
recommend  HQ  SSG  modify  the  SBSS  to  allow  deletion  of  records  with  a  maximum  level  zero 
detail  (type  detail  “E”)  with  file  status  or  manual  record  deletion  (FID  transaction).  This  change 
will  prevent  the  base  from  having  to  delete  the  maximum  levels  after  the  unit  returns  home. 

HQ  AMC  concerns  -  HQ  AMC  uses  the  maximum  levels  of  zero  in  their  Forward  Supply 
System  (FSS)  accounts  to  suppress  stockage  in  Forward  Supply  Locations  (FSL)  that  don’t  have 
the  maintenance  expertise  or  storage  space  for  certain  items.  AMC  also  consciously  maintains 
the  record  once  it  has  achieved  the  proper  deletion  criteria  because  it  is  a  required  item  for  the 
FSL.  When  an  aircraft  breaks  down,  the  maintenance  recovery  team  brings  the  asset  with  them 
to  effect  the  repair. 

HQ  AMC  also  uses  the  maximum  levels  of  zero  in  their  FSL  contingency  accounts.  They 
process  their  issue  requests  as  recurring  (to  accrue  the  demand  data),  but  they  do  not  want  to 
stock  the  item.  By  not  deleting  the  items  when  they  reach  the  automatic  deletion  threshold,  they 
can  further  reduce  the  workload  at  the  FSL  contingency  accounts  by  not  having  to  load  the  stock 
number  record.  The  record  also  has  the  re-supply  requisition  modifier  and  the  override  for 
repairable  destination  records  already  loaded  (because  it  wasn’t  deleted),  as  well  as  maintaining 
demand  data  on  the  item.  All  these  reasons  give  the  contingency  FSL  the  ability  to  maintain  a 
“ready-to-go”  condition. 

Longer  Term  Solutions  -  Load  the  base  closure  flag  to  all  applicable  records.  The  SBSS  will 
have  to  pass  the  base  closure  flag  indicator  to  RBL  (via  the  XCB).  Finally,  RBL  will  have  to  be 
modified  to  accept  the  base  closure  flag  and  treat  it  the  same  as  a  maximum  level  of  zero.  This 
longer-term  solution  will  eliminate  the  need  to  load  maximum  levels  of  zero  for  recoverable 
items. 


Clean-up  program 
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A  final  requirement  is  for  a  clean-up  program.  The  program  would  identify  NSNs  that  are 
erroneously  loaded  at  a  contingency  site  for  a  weapon  system  that  is  no  longer  at  that 
location  (i.e.,  demand  data  on  an  F- 15  NSN  at  an  F-16  location).  The  RBL  Central  Leveling 
Summary  (CLS)  would  be  a  useful  tool  to  identify  suspect  demand  data  for  Materiel  Manager 
and  MAJCOM  review  and  subsequent  clean  up.  We  propose  the  AF  Requirements  Team  and  the 
MAJCOMs  -  USAFE,  ACC,  and  PACAF  -  use  the  CLS  to  identify  and  delete  any  non- 
applicable  demands  and/or  levels  at  the  end  of  a  contingency  and/or  the  “final”  departure  of 
weapon  systems  from  a  contingency  site.  The  process  would  identify  any  weapon  system  item 
(by  system  management  code)  with  positive  demand  or  a  level  for  a  weapon  system  no  longer 
assigned  to  that  base.  The  contingency  site’s  host  MAJCOM  will  use  the  list  of  any  suspected 
erroneous  demand  and/or  levels  data  for  subsequent  clean-up. 

The  AF  Requirements  Team  will  develop  and  process  a  program/procedure  for  CHPMSK 
validation  and/or  clean-up  after  contingencies.  The  program  will  be  run  at  least  upon  elimination 
of  a  CHPMSK  at  a  location  that  no  longer  supports  the  weapon  system.  The  MAJCOMs  will 
perform  the  clean-up  process  using  the  CLS  for  all  cases  except  when  the  CHPMSK  is  deleted. 

Additionally,  SBSS  programs  need  to  be  modified  to  delete  stock  numbers  (with  maximum  level 
of  zero  details  loaded)  that  qualify  for  deletion.  For  example,  USAFE  manually  deleted  over 
10,000  stock  numbers  that  didn’t  belong  at  contingency  host  accounts  (after  deleting  all 
maximum  level  zero  details).  Once  all  the  demand  data  has  been  subtracted  from  the  stock 
numbers  and  transferred  to  the  host  bases,  they  should  qualify  for  automatic  deletion  during  file 
status  processing.  Unfortunately,  only  RBL  details  (type  detail  “F”  and  zero  quantity)  and  life  of 
system  stock  details  (level  justification  code  0)  are  allowed  to  exist  with  a  stock  number  and 
qualify  it  for  automatic  deletion  under  file  status  processing.  The  same  logic  exists  for  manual 
deletion  of  a  stock  number  when  using  SBSS  transactions  (TRIC  FID).  We  recommend  adding 
(or  changing  the  SBSS  to  include)  maximum  level  of  zero  details  (type  detail  “E”)  to  the  criteria 
for  automatic  stock  number  deletion  during  file  status  processing  as  well  as  FID  processing. 


PROPOSAL  TO  AF  SUPPLY  WARTIME  POLICY  GROUP  j AFSWPGI 


The  AFLMA  developed  and  proposed  two  options  to  the  Air  Force  Supply  Wartime  Policy 
Group  in  November  1999.  Both  options  require  each  unit  transferred  to  a  contingency  site  to 
segregate  unit  data  (i.e.,  establish  a  separate  organization  code)  and  to  record  all  demands  as 
recurring.  If  the  contingency  (host)  site  is  not  using  the  NSN  (the  item  is  not  applicable  to 
weapon  systems  permanently  assigned  to  the  host  site),  then  the  contingency  unit  should  load  a 
maximum  level  of  zero  when  the  units  transfer  in.  All  support  will  come  from  the  RSP  and 
CHPMSK.  If  the  item  is  currently  being  used  at  the  host  site,  RBL  will  allocate  to  that  base. 
RBL  will  not  compute  the  CHPMSK  level  as  part  of  the  POS  level.  So  the  CHPMSK  will  be 
computed  to  support  the  unit  transferring  in  and  RBL  will  allocate  a  POS  level  for  the  normally 
assigned  unit. 

Option  1,  Transfer  upon  unit  return  -  Transfer  the  demand  data  upon  return  of  the  unit  to  its 
home  base.  If  a  new  unit  is  to  replace  the  unit  leaving,  then  run  a  program  to  identify  unit 
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specific  demand  data  at  the  contingency  site.  Transfer  (delete  at  the  contingency  site)  the  unit 
demand  data  and  load  at  the  home  base.  Leave  the  host  base  demand  data  as  is,  but  delete  the 
demand  data  generated  by  the  unit  that  transferred. 

Option  2,  Transfer  at  the  end  of  the  contingency  -  All  returning  units  involved  “do  nothing”  for 
transferring  demand  data  until  the  contingency  is  over  (or  annually).  In  other  words,  let  all 
systems  report  the  failures  and  accrue  demand  data  under  normal  SBSS  procedures.  At  the 
transfer  point  (annually  or  at  the  end-of-contingency)  identify  the  unit  demands,  transfer  the 
demand  data  to  the  appropriate  home  station  and  delete  all  “contingency  demands”  at  the 
contingency  base.  Recompute  the  CHPMSK  if  it  is  the  annual  transfer  of  demand  data  and  the 
contingency  continues.  If  any  CHPMSK  was  in  use  and  was  an  annual  transfer,  the  updated 
CHPMSK  would  provide  the  levels  to  the  contingency  site  so  there  is  no  need  to  retain  the 
demand  data  at  the  contingency  location. 

Evaluation  of  options  -  A  concern  for  Option  2  is  that  most  units  transfer  quarterly,  and  if  a  unit 
transfers  to  the  home  base  and  leaves  all  demands  at  the  contingency  --  will  the  home  base  have 
the  demands  necessary  to  receive  adequate  levels  from  RBL?  The  returning  planes  accrued  zero 
demands  at  the  home  base,  but  they  are  relying  on  RBL  to  allocate  the  parts  to  continue  flying  - 
at  their  home  base. 

We  conducted  an  analysis  to  answer  that  question.  We  used  data  from  two  different  bases  and 
weapon  systems  (Pope/A- 10  and  Shaw/F-16)  and  the  RBL  model  to  compute  levels.  We  used 
the  demand  data  for  a  lull  base  (all  planes  present)  for  a  quarter,  then  projected  percentages  of  the 
aircraft  missing  for  several  quarters,  decremented  the  demands  for  those  quarters,  and  re-ran 
RBL.  Since  RBL  uses  the  SBSS  reported  base  demands  over  five  quarters,  one  quarter’s  demand 
data  may  not  significantly  reduce  RBL  allocations. 

Analysis  results  -  Our  analysis  shows  the  reduction  in  the  RBL  allocation  to  the  home  bases  was 
insignificant  (see  Appendix  B).  Basically,  missing  90  days  demand  data  did  not  significantly 
reduce  RBL  allocations  at  the  two  bases  we  modeled.  However,  the  AFSWPG  wanted  to  transfer 
the  demand  data. 

Option  summary  -  Summarizing  the  options,  Option  1  keeps  demand  data  with  the  unit.  It 
conceptually  provides  the  most  accurate  levels  allocation,  and  both  ACC  and  USAFE  prefer  this 
method.  It  is  more  complicated  than  Option  2.  Option  2  is  simple,  accurate  for  requirements, 
and  satisfactory  for  levels  allocation. 

Supply  War  Policy  Group  Data  Collection  and  Reporting  System  Requirements 

The  Air  Force  Supply  War  Policy  Group  (AFSWPG)  preferred  Option  1  with  slight 
modifications.  The  workgroup  requirements  were  as  follows: 

1 .  If  the  item  is  not  currently  used  at  the  host  (contingency)  site,  use  maximum  level 
zero  and  recurring  demands  (unless  it  is  a  true  non-recurring  demand).  Support  will 
be  provided  from  the  RSP  and/or  the  CHPMSK. 
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2.  If  the  item  is  currently  used  at  the  host  (contingency)  site,  do  not  use  a  maximum 
level  of  zero.  Change  RBL  to  allocate  levels  to  the  host  site  via  reported  demands 
(separate  and  additive  to  the  CHPMSK). 

3.  Use  the  ACC  L73  to  collect  each  unit’s  demand  data  upon  return  of  the  transferred 
unit.  The  L73  program  will  collect  data  using  the  unique  organization  code  (or  SRD) 
for  the  contingency  unit. 

4.  Transfer  the  demand  data  when  the  unit  returns  to  the  home  base. 

5.  Recompute  CHPMSK  with  new  demand  data  annually. 

6.  Delete  the  transferred  unit’s  demand  data  from  the  contingency  base  upon  return  of 
the  unit  to  the  home  base. 

7.  Modify  RBL  to  honor  CHPMSK  plus  any  base  demand  (except  maximum  level  zero). 
Currently,  the  CHPMSK  levels  are  subtracted  from  the  base  levels,  so  levels  are  not 
allocated  above  the  CHPMSK  unless  there  has  been  sufficient  demand  to  earn  the 
higher  levels. 

8.  The  AF  Requirements  Team  develop  a  program  to  identify  data  that  is  not  properly 
transferred  upon  completion  of  a  contingency. 

9.  Bases  take  action  to  ensure  contingency  demands  that  do  not  reflect  peacetime 
demand  rates  do  not  generate  erroneous  requirements  and  RBL  levels  (we  discuss  this 
more  below). 

10.  AFLMA  is  to  write  the  procedures  for  contingency  demand  data  transfers  to  be 
included  in  AFMAN  23-110,  Vol  2,  Part  2,  Chapter  26  (see  Appendix  A).  Prior  to 
formal  publication  in  AFMAN  23-110,  these  procedures  will  be  distributed  to  the 
MAJCOMs  as  draft  procedures. 

Reviewing  and  Filtering  Wartime  Demand  for  Peacetime 

In  this  section,  we  amplify  the  requirements  (8  and  9  above)  to  review  and  filter  contingency 
demands  for  peacetime  use.  The  objective  is  to  ensure  the  demand  data  collected  and  used  for 
peacetime  requirements  and  levels  allocation  reflects  peacetime  demand  rates.  If  an  item’s 
failures  in  the  contingency  (i.e.,  wartime  setting)  do  not  reflect  normal  peacetime  flying  (e.g., 
electronic  countermeasures,  gun  parts),  then  those  failures  should  not  be  used  to  compute 
peacetime  requirements  or  levels.  In  addition,  once  all  contingency  units  return  to  their  home 
base,  the  Air  Force  should  ensure  all  demand  data  for  units  that  transferred  home  is  purged  from 
the  host  (contingency)  site.  For  example,  no  F-15  data  should  remain  at  a  host  site  that  has  no  F- 
15s  assigned. 

Segregating  Wartime  Demand  Data  -  We  suggest  the  Air  Force  identify  wartime  from  peacetime 
demands  and  separately  accumulate  both  types  of  demand.  This  would  be  the  best  source  of 
peacetime  levels  calculations  and  wartime  requirements  forecasting. 

One  method  of  segregating  peace  from  war  demand  data  would  require  changes  to  the  current 
SBSS.  Specific  wartime  demands  would  have  a  unique  demand  code,  to  be  used  for  specific 
wartime  demands.  The  special  demand  code  would  be  used  for  applicable  wartime  demands  for 
the  host  base  as  well  as  the  contingency  unit.  The  purpose  of  the  demand  code  is  to  identify 
demands  that  shouldn’t  count  for  peacetime  levels  (for  example,  electronic  warfare  components, 
gun  barrel  replacement,  etc.).  The  SBSS  will  store  the  demands  separately  (i.e.,  on  parallel  item, 
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repair  cycle  and  SRD  consumption  records).  These  demands  will  not  be  used  for  computing 
peacetime  demand  levels  (i.e.,  not  reported  on  the  XCBs).  The  SBSS  will  report  these  demands 
to  D041  using  the  wartime  demand  code;  these  failures  will  be  recorded  at  AFMC  via  the  7WS 
and/or  the  DAC),  but  not  used  for  peacetime  demand  computations.  All  supply  records  that  store 
demand  data  would  have  separate  wartime  and  peacetime  accumulators.  The  item,  repair  cycle 
and  SRD  consumption  records  would  then  have  all  the  data  necessary  for  POS  levels  and 
wartime  requirements  computation. 

All  wartime  contingency  data  for  units  that  transfer  should  retain  their  contingency  data  for 
forecasting  wartime  failures.  When  contingency  units  transfer  their  data  back  to  the  home  base, 
the  data  will  be  stored  in  the  separate,  parallel  SRD  consumption  records.  Note  the  data  will  be 
transferred  to  the  home  base  item  and  repair  cycle  record  like  today  (except  those  demands  using 
the  wartime  demand  code).  The  segregated  SRD  consumption  record  data  will  be  used  to 
review/recompute  Contingency  High  Priority  Mission  Support  Kit  (CHPMSK)  and  to  provide  a 
basis  to  forecast  RSP  failure  rates. 

Deleting  data  at  the  end  of  the  contingency  -  A  lesson  learned  from  the  transfer  of  Kosovo  data 
was  that  not  all  contingency  failure  data  was  deleted  for  the  contingency  supply  account.  A 
USAFE  base  continued  to  report  demand  (and  received  RBL  levels)  for  a  weapon  system  that 
was  not  present  at  that  site.  We  propose  the  AF  Requirements  Team  and  the  owning  SRAN’s 
MAJCOM,  upon  completion  of  the  contingency,  ensure  all  demand  data  and/or  levels  for  any 
RBL  NSNs  on  weapon  systems  not  assigned  to  that  base  are  identified.  MAJCOMs  should 
review  and  take  proper  action  before  RBL  is  run.  The  AF  Requirements  Team  should  also 
develop  a  program/procedure  to  review  and  delete  non-applicable  demand  and  levels  data  for  the 
NSNs  that  were  in  the  CHPMSK. 

Contingency  failure  data  reporting 

Today,  all  contingency  failure  data  is  reported  to  D041  via  DAC  transactions.  We  propose  that 
all  contingency  demand  data  be  recorded  at  the  contingency  site,  transferred  to  the  home  station 
(when  the  aircraft  return  to  the  home  base)  and  reported  via  the  7WS  to  D041  (from  either  the 
base  where  the  aircraft  reside).  The  home  base  should  record  all  failure  data  on  the  item,  repair 
cycle  and  SRD  consumption  records.  However,  maintenance  and  supply  managers  at  the  home 
base  must  identify  any  contingency  demands  not  applicable  to  home  base  peacetime  flying  (due 
to  opstempo,  climatic  conditions  or  wartime  unique  failures)  and  use  maximum  levels  and/or  the 
special  wartime  demand  code  to  constrain  the  peacetime  level.  This  also  means  the  AFMC 
material  manager  (MM)  and  equipment  specialist  (ES)  must  modify  failure  rates  for  D041 
peacetime  requirements  computation.  AFMC  should  record  demands  with  the  special  wartime 
code  and  not  include  those  failures  in  peacetime  requirements  computations.  We  prefer  to  report 
all  demand  data.  We  think  it  is  important  to  record  and  rehome  the  actual  demand  data  and  then 
exclude  demands  with  the  special  demand  code  and/or  manually  adjust  the  demand  for 
requirements  and  levels  allocation. 
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Demand  data  transfer  timing 

Care  should  be  taken  if  the  unit  returns  to  the  home  base  at  the  end  of  a  quarter  (March,  June, 
September  and  December)  because  the  end-of-quarter  failure  data  (7WS)  must  be  reported  from 
one  and  only  one  site  -  either  the  contingency  site  or  the  home  base.  For  example,  do  not  run  the 
ACC  L73  at  the  contingency  site  after  the  quarterly  option  of  the  D28  has  been  processed  there 
and  then  turn  around  and  run  the  ACC  L73  at  the  home  base  before  the  quarterly  option  of  the 
D28  is  run  there.  This  would  result  in  duplicate  reporting.  Also,  do  not  eliminate  the  data  at  the 
contingency  site  before  running  the  quarterly  option  of  the  D28  and  then  load  the  data  at  the 
home  base  after  running  the  quarterly  option  of  D28.  This  would  result  in  no  reporting. 
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CHAPTER  4 


CONCLUSIONS  AND 
RECOMMENDATIONS 


CONCLUSIONS 

1 .  There  is  no  standard  procedure  for  recording,  reporting,  and  transferring  contingency  demand 
data. 

2.  There  is  no  standard  program  to  collect  transferred  unit  data  and  update  home  base 
records.  The  ACCL73  currently  collects  demand  data  to  transfer. 

3.  There  is  no  supply  TRIC  to  accurately  update  the  SRD  consumption  records. 

4.  There  is  no  method  to  separate  peacetime  and  wartime  demands. 

5.  The  Air  Force  Wartime  Supply  Policy  Group  approved  transferring  demand  data  when  the 
weapon  system  returns  to  their  home  base. 

6.  The  base  closure  flag  suits  the  need  better  than  maximum  levels  of  zero  for  suppressing 
contingency  levels. 

RECOMMENDATIONS 

1.  Approve  and  post  our  proposed  procedures  (Appendix  A)  for  AFMAN  23-1 10,  Volume  2, 
Part  2,  Chapter  26,  Section  O,  Contingency  Demand  Data  Recording,  Reporting,  and 
Transferring  (Appendix  A).  The  proposed  procedures  are  based  upon  the  AFWSPG 
recommendations  and  the  ACC  L73  program.  (OPR:  USAF/ILSP) 

2.  As  an  interim,  post  the  ACC  L73  SURGE  program  on  a  web  site  along  with  the 
documentation  to  process  the  program  (OPR:  ACC/RSSM)  and  mandate  its  use 
(OPR:  USAF/ILSP). 

3.  Enhance  the  L73  to  (a)  produce  dynamic  files  based  upon  the  input  parameters  and  (b) 
produce  the  FCL/FRR  files  to  subtract  the  transferred  demands  from  the  contingency  site 
records  (Appendix  C).  (OPR:  ACC/RSSM) 

4.  Using  the  ACC  L73  as  a  guide,  develop  a  permanent  SBSS  program(s)  to  perform  the  same 
functions  with  our  proposed  enhancements.  (OPR:  USAF/ILSP  OCR:  SSG/ILS) 

5.  Develop  a  supply  TRIC  to  add/delete/update  the  SRD  consumption  records. 

(OPR:  USAF/ILSP  OCR:  SSG/ILS) 

6.  Modify  RBL  to  allocate  base  levels  separately  from  CHPMSK  levels. 

(OPR:  AFMC/LGI  and  AFLMA/LGS) 

7.  Upon  completion  of  the  contingency,  MAJCOMs  should  use  the  RBL  Central  Leveling 
Summary  (CLS)  to  identify  and  delete  any  levels  or  demand  changes  for  any  RBL  NSNs  at 
the  contingency  base  for  weapon  systems  that  are  no  longer  assigned  to  that  base. 

(OPR:  ACC,  USAFE,  and  PACAF) 
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8.  Upon  elimination  of  a  CHPMSK  at  a  location  that  no  longer  supports  the  weapon  system,  use 
the  RBL  CLS  to  ensure  all  demand  and  levels  data  is  purged  from  the  SBSS  and  CLS  files. 
(OPR:  Air  Force  Requirements  Team  AFLMA/LGS  and  AFMC/LGI) 

9.  Implement  a  system  to  ensure  7WS  transactions  are  received  from  all  bases. 

(OPR:  AFMC/LGI  OCR:  SSG/ILS) 

10.  Develop  procedures  for  identifying  and  separately  recording  wartime  from  peacetime 
demands.  (OPR:  USAF/ILSP) 

1 1 .  Modify  the  SBSS  to  identify  a  stock  number  with  a  base  closure  flag  to  RBL  via  the  XCB 
transaction.  (OPR:  USAF/ILSP  OCR: SSG/ILS) 

12.  Modify  RBL  to  accept  the  base  closure  flag  and  treat  it  as  a  maximum  level  of  zero. 

(OPR:  USAF/ILSP  OCR:  AFMC/LGI) 

13  Modify  the  logic  for  manual  stock  number  deletion  during  FID  processing  to  include  deleting 
item  records  with  a  maximum  level  of  zero  detail  (type  detail  “E”). 

(OPR:  USAF/ILSP  OCR:  SSG/ILS) 

DISTRIBUTION :  Refer  to  attached  Standard  Form  298. 
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APPENDIX  A 


Proposed  Procedures  for  AFMAN  23-110, 
Vol  2,  Part  2,  Chapter  26 

Section  260  -  RECORDING,  REPORTING,  AND  TRANSFERRING  DEMAND  DATA  AT  A 
CONTINGENCY  SUPPORT  BASE 

26.103.  Overview. 

26.103.1.  Section  Summary.  This  section  describes  programs  and  procedures  to  ensure  that 
demands  experienced  in  a  contingency  environment  are  properly  recorded  in  the  SBSS  (on  item, 
repair  cycle,  and  SRD  consumption  records);  reported  to  D041  (Recoverable  Consumption  Item 
Requirements  System)  and  D035E  (RBL);  transferred  back  to  home  base  when  the  unit  re¬ 
deploys  so  they  will  be  available  to  support  future  levels  and  RSP  computations;  and  used  for 
CHPMSK  review  and/or  annual  validation.  These  procedures  apply  in  all  instances  where  an  Air 
Force  unit  chooses  to  transfer  (versus  deploy)  readiness  spares  packages. 

26.103.2.  Policy.  It  is  imperative  that  units  record,  report,  and  transfer  demand  data  correctly 
because  this  data  drives  the  AF’s  buy/repair  programs  and  is  used  to  allocate  readiness  based 
levels. 

26.103.2.1.  Recording.  Proper  recording  of  demands  ensures  that  usage  data  will  be  available 
to  compute  more  accurate  levels  (both  peacetime  and  wartime).  Unless  otherwise  specified,  all 
demands  experienced  in  a  contingency  environment  will  be  processed  as  recurring  (demand  code 
R).  Each  unit  that  transfers  into  a  contingency  environment  will  also  be  assigned  a  unique 
organization  code  that  will  be  used  when  ordering.  It  is  also  imperative  that  the  correct  SRD  be 
used  on  all  orders.  The  combination  of  the  unique  organization  code,  proper  SRD,  and  demand 
code  R  will  facilitate  the  reporting  and  transferring  processes. 

26.103.2.2.  Reporting.  Reporting  demands  actually  encompasses  reporting  reparable 
generations  (failures)  to  the  D041  for  wholesale  requirements  computation  and  usage  data  to 
D035E  for  readiness  based  leveling.  Reparable  generations  are  reported  to  the  D041  on  a  daily 
basis  as  they  occur  via  DAC  transactions  generated  through  the  daily  RAMPS  (D28)  report.  A 
summary  of  all  reparable  generations  is  also  reported  to  D041  quarterly  via  7WS  transactions 
generated  through  the  quarterly  option  of  the  RAMPS  (D28)  report.  Normally,  reparable 
generations  will  be  reported  from  the  contingency  site  because  the  D041  does  not  care  where 
failures  occur.  However,  when  demand  data  is  transferred,  care  must  be  taken  to  ensure  that 
reparable  generations  are  not  reported  from  both  the  home  base  and  the  contingency  site.  Usage 
data  is  reported  to  the  D035E  quarterly  via  XCB  transactions.  This  data  is  used  to  compute 
readiness  based  levels,  which  are  not  normally  desired  to  support  the  deployed  unit  at  the 
contingency  site.  Therefore,  the  base  closure  flag  (for  all  items)  and  maximum  levels  of  zero 
(for  RBL  items)  will  be  used  to  suppress  POS  levels  (both  RCDLs  and  RBLs)  on  all  items  that 
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are  not  normally  used  at  contingency  sites,  i.e.,  on  item  records  loaded  to  support  units  deploying 
into  the  contingency  site.  The  base  closure  flag  will  prevent  stockage  of  the  items,  but  allow 
demand  data  to  accrue.  The  maximum  levels  will  ensure  that  RBL  does  not  allocate  a  level  for 
the  contingency  site  despite  any  usage  data  that  is  reported.  Maximum  levels  should  not  be  used 
if  the  host  unit  at  the  contingency  site  uses  the  item  because  RBL  will  still  allocate  levels  to 
support  the  host  site’s  needs.  If  CHPMSK  levels  are  used  to  support  the  contingency  unit,  then 
the  CHPMSK  levels  plus  the  RBL  level  will  support  both  the  host  unit  and  the  deployed  unit’s 
needs.  While  it  is  highly  desirable  to  have  the  usage  data  reported  from  the  home  base  (for  use  in 
future  levels),  it  is  not  absolutely  imperative  that  the  contingency  usage  data  be  reported  from  the 
home  base  in  the  quarter  that  it  occurred.  An  AFLMA  study  proved  that  the  DDR’s  sensitivity  to 
the  change  in  usage  during  the  transfer  period  is  negligible. 

26.103.2.3.  Transferring.  Transferring  demand  data  back  to  home  base  after  a  unit  re-deploys 
will  ensure  that  the  data  is  used  to  compute  more  accurate  POS  levels  (RBLs)  and  also  that 
consumption  data  will  be  available  for  accurate  RSP  computations.  Transferring  demand  data 
includes  the  process  of  identifying  relevant  demands  that  occurred  at  the  contingency  site  and 
then  moving  them  back  to  the  home  bases  records.  It  also  includes  deleting  the  demands  from 
the  contingency  site  and  sending  a  copy  of  the  data  to  the  contingency  host  MAJCOM.  In  order 
to  ensure  this  is  done  properly,  contingency  processing  must  include  the  use  of  a  unique 
organization  code,  the  correct  SRD,  and  a  recurring  demand  code.  When  the  contingency  unit  is 
returning  home,  an  ACC  developed  SURGE  (ACC  L73)  program  will  be  used  to  gather  all 
contingency  demand  data  from  the  Consolidated  Transaction  History  (CTH)  area  for  transfer  and 
upload  at  the  home  base.  NOTE:  ACC  L73  will  be  used  until  a  standard  program  is  developed 
and  released  by  the  Standard  Systems  Group.  NOTE:  However,  for  long-term  contingencies 
MAJCOMs  may  choose  to  retain  demand  data  at  the  contingency  site  instead  of  deleting  the  data 
as  the  unit  returns  to  it’s  home  base.  If  this  option  is  chosen,  the  contingency  site  must  have 
maximum  levels  of  zero  loaded  to  prevent  RBL  from  pushing  duplicate  levels.  The  L73  must  be 
used  to  create  a  copy  of  the  demand  data  to  upload  to  the  home  base  (using  the  same  data  files  as 
the  data  transfer).  In  this  case  the  data  is  not  being  transferred,  but  copied  to  the  home  base. 
Demand  data  upload  to  the  home  base  must  be  closely  monitored  to  insure  the  data  is  not 
reported  or  transferred  twice.  During  long-term  contingencies,  the  data  must  be  loaded  to  the 
home  base  after  end-of-quarter  processing  has  occurred  at  both  the  contingency  site  and  the 
home  base.  This  ensures  the  failure  data  (7WS)  is  only  reported  to  D041  once.  If  possible,  the 
data  should  be  loaded  at  the  home  base  within  the  first  10  days  of  the  new  quarter  for  proper 
RBL  allocation. 

26.104.  Responsibilities 

26.104.1.  Major  Command  Managers  (of  both  Gaining  and  Deploying  Units).  Facilitate 
the  transfer  of  units/RSPs  and  ensure  demand  data  is:  (a)  successfully  transferred  back  to 
deploying  unit’s  home  base,  (b)  maintained  at  the  MAJCOM  (a  copy  of  the  demand  data 
transferred),  (c)  deleted  from  the  contingency  site,  and  (d)  reported  to  wholesale  systems 
correctly.  MAJCOM  managers  must  furnish  contingency  demand  data  files  to  the  Air  Force 
Logistics  Management  Agency  (AFLMA)  Requirements  Team  for  annual  CHPMSK  validations. 

26.104.2.  Base  Contingency  Processing  Manager  at  Home  Base. 
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26. 1 04.2. 1 .  Coordinate  with  Major  Command  Manager 

26.104.2.2.  Ensure  RSP  transfer  procedures  are  followed. 

26.104.2.3.  Establish  and  maintain  a  contingency  demand  data  transfer  file  that  contains  all 
correspondence  related  to  the  transfer,  including  copies  of  the  input  and  output  from  processing 
ACC  L73  program. 

26. 104.2.4.  Coordinate  with  gaining  CSB  to  ensure  demand  data  is  identified  for  transfer  back 
to  home  base  (ACC  L73  is  processed)  when  units  re-deploy. 

26.104.2.5.  Coordinate  with  Maintenance  personnel  to  review  demand  data  to  identify  items 
that  were  used  during  the  contingency  that  will  not  be  used  as  extensively  to  support  peacetime 
operations  (e.g.,  electronic  warfare  items,  gun  parts,  etc.).  Filter  out,  change,  or  suppress  (using 
Maximum  levels)  the  demand  data  for  these  items.  The  use  of  maximum  levels  is  recommended 
because  this  ensures  the  demand  data  remains  available  to  support  other  processes.  For  example, 
if  an  EW  item  was  used  extensively  during  the  contingency,  but  only  periodically  during 
peacetime,  the  demand  data  could  still  be  transferred  and  a  maximum  level  of  1  could  be  loaded 
to  limit  stockage.  Regardless  of  the  method  chosen,  the  data  used  to  update  the  SRD 
consumption  records  should  be  unfiltered. 

26. 104.2.6.  Monitor  the  processing  of  files  produced  by  ACC  L73. 

26.104.3.  Senior  Deploying  Supply  Person. 

26.104.3.1.  Maintain  accountability  of  RSP  as  defined  in  transfer  procedures. 

26.104.3.2.  Ensure  all  demands  at  the  contingency  site  are  processed  correctly  (using  demand 
code  R,  the  appropriate  Organization  code,  and  the  correct  SRD). 

26.105.  Processing  Contingency  Demand  Data.  Specific  tasks  and/or  duties  are  required  in 
three  phases  -  prior  to  the  unit’s  arrival  at  the  contingency  location,  during  the  unit’s  operation  at 
the  forward  location,  and  after  the  unit  returns  to  the  home  base.  These  procedures  augment 
RSPs  transfer  procedures  in  Chapter  26,  Section  C. 

26.105.1.  Prior  to  the  deployed  unit’s  arrival  at  the  contingency  site. 

26.105.1.1.  CSB  supporting  the  contingency  site  must  load  a  unique  organization  record  for  the 
arriving  unit  and  furnish  the  organization  code  to  the  home  base  RPS  for  processing  of  program 
NGV471  (Chapter  6,  Attachment  A- 14). 

26.105.1.2.  Home  base  must  ensure  all  files  have  been  created  for  the  RSP  being  transferred 
using  program  NGV471  (Chapter  6,  Attachment  A-14)  and  forward  the  files  to  the  gaining  CSB. 
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26.105.1.3.  CSB  supporting  the  contingency  site  must  load  all  incoming  files  from  the  home  base 
under  the  organization  code  designated  for  the  inbound  unit  (program  NGV466,  Chapter  6, 
Attachment  A-l  1). 

26.105.1.4.  CSB  supporting  the  contingency  site  must  load  the  base  closure  flag  to  all  item 
records  the  home  base  doesn’t  normally  use,  e.g.,  to  new  item  records  loaded  for  the  inbound  unit 
(1F3,  Chapter  19,  Attachment  B-l)  and  load  maximum  levels  of  zero  to  all  XD2  item  records. 

26.105.2.  During  the  contingency  processing  at  contingency  site. 

26.105.2.1.  Transferred  unit  must  process  all  issues  and  backorders  using  the  appropriate 
organization  code,  SRD,  and  demand  code.  Demand  code  R  (recurring)  should  be  used  for  all 
demands  unless  they  were  not  generated  by  a  failure  (mishap,  tech  order  change,  etc.). 

26.105.2.2.  CSB  at  contingency  site  must  ensure  the  D28  RAMPS  report  images  are  transmitted 
successfully  at  each  end-of-day  (EOD).  At  the  end-of-quarter  (EOQ)  the  D28  should  include 
7WS  images. 

26. 105.3.  Transferred  unit  returns  to  home  base. 

26.105.3.1.  CSB  supporting  the  contingency  site  must  ensure  all  files  have  been  created  for  the 
returning  RSP  using  program  NGV471  (chap  6A-14)  and  forward  the  files  to  the  home  base 
computer  operations  section  for  processing. 

26.105.3.2.  CSB  supporting  the  contingency  site  must  identify  and  collect  the  demand  and  repair 
(item  and  repair  cycle)  data  associated  with  the  returning  unit.  ACC  L73  will  be  used  to  collect 
the  data  from  the  CTH  record.  This  data  will  be  used  to  update  (add  demands)  to  the  home 
bases  records  and  to  eliminate  (subtract  demands)  from  the  contingency  site  item  and  repair  cycle 
records.  NOTE:  Care  should  be  taken  if  the  unit  returns  to  the  home  base  at  the  end  of  a  quarter 
(March,  June,  September  and  December)  because  the  end-of-quarter  failure  data  (7WS)  must  be 
reported  from  one  and  only  one  site  -  either  the  contingency  site  or  the  home  base.  For  example, 
do  not  run  the  ACC  L73  at  the  contingency  site  after  the  quarterly  option  of  the  D28  has  been 
processed  there  and  then  turn  around  and  run  the  ACC  L73  at  the  home  base  before  the  quarterly 
option  of  the  D28  is  run  there.  This  would  result  in  duplicate  reporting.  Also,  do  not  eliminate 
the  data  at  the  contingency  site  before  running  the  quarterly  option  of  the  D28  and  then  load  the 
data  at  the  home  base  after  running  the  quarterly  option  of  D28.  This  would  result  in  no 
reporting. 

26.105.3.2.1.  The  ACC  L73  program  is  available  from  the  ACCRSS  website 
('http://www.accrss.lannlev.af.mil/reports/L73/').  Download  both  the  L73CONTINGENCY.TXT 
(program  file)  and  L73-PARA.TXT  (example  parameter)  files  from  the  web  site.  The  following 
information  (parameters)  are  needed  to  process  the  L73  and  get  the  proper  records  from  the 
contingency  SBSS: 

-  Date  the  unit  arrived  at  the  contingency  site  (yyyyddd,  four-digit  year  with  the 
three-digit  Julian  date,  ex.  2000091) 
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Date  the  unit  left  the  contingency  site  (ex.  2000181) 

-  SRD  used  while  at  the  contingency  site  (ex.  AAC) 

Contingency  site  system  designator  (ex.,  Al) 

-  Host  base  system  designator  (ex.,  01) 

Contingency  site  organization  code  (ex.,  674). 

-  Qualifier/filename  of  program  file  for  multiple  runs  (ex.,  1GV0*L73-TRANS.) 

Catalog  a  file  on  the  system  named  1GV0*L73-PARA  in  which  to  place  the  parameters 
(mentioned  above)  for  the  L73.  Also  catalog  the  program  file  specified  in  the  parameters  if 
processing  multiple  runs  of  the  L73. 

NOTE:  For  multiple  SRDs  or  organizations,  the  program  file  must  be  specified  in  the  file 
1GV0*L73-PARA  (see  example  above).  The  element  names  for  each  run  of  the  L73  will  be 
FCL/<SRD>-<ORG>  and  FRR/<SRD>-<ORG>  where  SRD  equals  the  SRD  in  the  parameter 
and  ORG  equals  the  organization  code  in  the  parameter  (ex.,  lGV0*L73-TRANS.FCL/ABA-300 
and  lGV0*L73-TRANS.FRR/ABA-300).  CAUTION:  The  program  file  option  must  be  used 
with  multiple  runs  of  the  L73  (via  the  input  parameters)  or  the  data  will  be  deleted  and  rewritten 
during  each  run  of  the  L73. 


26.105.3.2.2.  After  processing  the  L73,  contact  the  home  base  computer  operations  section  to 
get  passwords  for  file  transfers.  Transfer  the  following  files  for  single  unit  processing  to  the 
home  base:  1GV0*L73-FCL  and  1GV0*L73-FRR.  Transfer  the  program  file  (specified  in  the 
input  parameter)  for  multiple  unit  processing  to  the  home  base. 

26.105.3.3.  CSB  supporting  the  contingency  site  must  process  the  FCLs  and  FRRs  produced  by 
the  L73  to  subtract  the  demands  being  transferred  from  the  records  at  the  contingency  site.  The 
file  1GV0*L73-FCL1S  has  the  action  taken  code  of  “S”  to  subtract  the  appropriate  demands 
from  the  CSB.  NOTE:  The  L73  has  a  pending  change  to  provide  the  file  1GV0*L73-FRR1S 
with  action  taken  code  of  “S”  to  subtract  the  appropriate  repair  cycle  data  from  the  CSB. 

26.105.3.4.  The  home  base  will  receive  the  data  file  or  program  file  from  the  contingency  site  to 
update  the  home  base’s  item  and  repair  cycle  records.  The  files  will  also  be  used  to  update  the 
home  base  SRD  consumption  records  and  build  transactions  to  force  RAMPS  reporting.  Once 
processed,  the  home  base’s  demand  data  will  appear  like  the  weapon  system  never  left  the  home 
base. 

26.105.3.4.1.  If  a  single  run  of  the  L73  was  processed  at  the  contingency  site,  process  the  FRR 
and  FCL  files  transferred  from  the  contingency  site  (1GV0*L73-FRR  and  1GV0*L73-FCL) 
through  the  pseudo.  If  a  multiple  run  of  the  L73  was  processed,  each  FRR  element  and  each  FCL 
element  must  be  processed  through  the  pseudo  (ex.,  lGV0*L73-TRANS.FRR/ABA-300  and 
lGV0*L73-TRANS.FCL/ABA-300).  Correct  any  rejects  before  processing  other  files. 

26.105.3.4.2.  Retrieve  the  home  base  ACC  L73  (L73HOMEBASE.TXT)  from  the  ACCRSS 
website  (http://www.accrss.langlev.af.mil/reports/L73/).  Before  processing  the  program,  change 
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the  SRD  in  the  program  to  match  the  SRD  in  the  FCL  images  previously  processed  through  the 
pseudo.  NOTE:  For  multiple  runs,  the  program  will  have  to  be  processed  once  for  each  SRD. 

26.105.3.4.3.  After  changing  the  SRD,  process  the  HOMEBASE  L73  program.  The  program 
will  use  the  FCLs  in  file  1GV0*L73-FCL  to  create  two  files  for  processing:  1GV0*L73-XCD 
and  1GV0*L73-QLP.  NOTE:  If  multiple  runs  of  the  L73  were  accomplished  at  the  contingency 
site,  you  must  copy  each  FCL  element  into  1GV0*L73-FCL  and  process  the  HOMEBASE  L73 
once  for  each  SRD  (FCL  element). 

26.105.3.4.4.  Next,  you  should  run  the  END  card  and  take  a  file  dump  of  the  primary  database 
prior  to  processing  the  QLP  file.  Then  you  must  process  the  QLP  file.  This  will  require  access 
to  QLP  with  UPDATE  using  the  correct  INVOKE  statement  for  the  primary  database.  Remember 
that  this  is  a  file  alteration  and  a  fix  document  must  be  prepared.  If  any  problems  occur,  you 
must  reload  the  dump  taken  prior  to  the  UPDATE  before  trying  it  again. 

NOTE:  If  there  are  multiple  organizations/SRDs  the  program  will  have  to  be  processed  against 
the  applicable  FCL  file  for  the  organization  or  SRD.  If  additional  runs  of  this  program  are 
required  -  save  off  the  1GV0*L73-XCD  and  1GV0*L73-QLP  files  after  each  good  EOJ  of  the 
home  base  portion  of  the  L73. 

26.105.3.4.5.  The  final  step  is  to  process  the  XCD  file  through  the  pseudo  and  correct  any 
rejects. 

26.105.3.4.6.  Repeat  these  steps  as  necessary  for  each  set  of  organization/SRD  files. 

26.105.3.5.  All  incoming  RSP  files  from  the  contingency  site  must  be  loaded  under  the  proper 
organization  code  (used  prior  to  the  deployment)  by  program  NGV466  (chapter  6,  Attachment  A- 
11). 
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APPENDIX  B 


Comparing  Home  Base  RBL  Levels 
Without  Contingency  Demand  Data 


We  are  interested  in  the  potential  effect  on  levels  with  the  loss  of  demand  data  at  home  base  for 
aircraft  temporarily  transferred  to  another  location.  One  option  is  to  leave  the  demand  data  at  the 
contingency  site  when  the  aircraft  return  to  the  home  base  since  the  contingency  site  may  need 
that  data  for  its  (POS)  levels.  Leaving  the  demands  at  the  contingency  site  will  bias  home  base 
demands  to  be  smaller  than  they  should  be,  since  it  will  not  include  the  demand  that  occurred  at 
the  contingency  site.  Note  the  SBSS  uses  up  to  540  days  of  demand  history,  so  leaving  90  days  of 
demand  data  at  the  contingency  site  may  not  have  a  significant  impact  on  home  base  levels.  Of 
course  this  assumes  aircraft  return  after  90  days. 

We  modeled  the  change  in  the  base  RBL  levels  and  Expected  Back-Orders  (EBO)  when  the 
aircraft  returned  but  didn’t  backfill  data  that  occurred  at  the  contingency  site  for  the  quarter  they 
were  transferred.  Specifically,  we  modeled  the  cases  below  using  January  1999  RBL  data.  We 
checked  with  ACC  to  ensure  that  no  aircraft  were  transferred  in  the  quarter  before  January  1999 
(Oct  98  -  Dec  98).  So  for  the  baseline  we  used  the  January  1999  RBL  demand  rate.  We  then 
decreased  the  daily  demand  rate  (DDR)  by  1  quarter’s  demand  (simulating  a  90-day  transfer  of 
the  aircraft). 

-  At  Pope,  which  had  28  A-10's,  we  modeled  4  (1/7)  and  14  (1/2)  of  the  aircraft  transferring 
for  a  quarter  and  returning 

-  At  Shaw,  which  had  72  F-16's,  we  modeled  24  (1/3)  and  48  (2/3)  of  the  aircraft 
transferring  for  a  quarter  and  returning 

We  set  up  RBL  to  use  the  daily  demand  rate  for  five  previous  quarters  of  demand  data  as  if  the 
first  four  had  all  aircraft  present  and  the  last  quarter  had  only  the  reduced  number  (those  not 
transferred).  We  compared  the  base  RBL  levels  and  EBOs  results  for  each  base  to  the  case 
where  all  the  aircraft  (and  their  demands)  were  present  for  all  five  quarters.  To  estimate  EBOs, 
we  used  the  RBL  levels  results  for  the  previous  (transferred)  quarter,  but  factored  the  demands 
back  up  to  that  for  all  aircraft  being  present  for  all  five  quarters.  We  compared  these  results  to 
the  case  where  all  the  aircraft  were  present  all  five  quarters.  The  results  from  our  modeling  are 
presented  in  table  B-l . 
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Pope  (FB4488  -  28  A-10's,  279  NSNs) 

-  4  A/C  deploy  and  return,  no  data  backfill 

-  Change  in  Pope  EBO  (all  NSNs)  =  +1.99  (+1.84  in  one  NSN) 


Delta  RBL 

Qty 

%  of  all 

-2 

l 

0.4% 

-1 

5 

1 .8%  (2  of  5  NSNs  reduced  to  0) 

0 

273 

97.8% 

14  A/C  deploy  and  return,  no  data  backfill 

Change  in  Pope  EBO  (all  NSNs)  =  +7.21  (+6.55  in  one  NSN) 


Delta  RBL 

Qty 

%  of  all 

-7 

1 

0.4% 

-1 

17 

6.1%  (7  of  17  NSNs  reduced  to  0) 

0 

261 

93.5% 

Shaw  (FB4803  -  72  F-16's,  392  NSNs) 

-  24  A/C  deploy  and  return,  no  data  backfill 

Change  in  Shaw  EBO  (all  NSNs)  = 

+0.94 

Delta  RBL 

Qty 

%  of  all 

-1 

17 

4.3%  (4  of  17  NSNs  reduced  to  0) 

0 

375 

95.7% 

-  48  A/C  deploy  and  return,  no  data  backfill 

-  Change  in  Shaw  EBO  (all  NSNs)  = 

+2.09 

Delta  RBL 

Qty 

%  of  all 

-1 

32 

8.2%  (9  of  32  NSNs  reduced  to  0) 

0 

360 

91.8% 

Table  B-l,  Demand  Data  Modeling  Results 


Note  delta  RBL  is  the  RBL  level  for  the  reduced  case  minus  that  for  the  full  case,  so  a  negative 
(-)  value  means  a  reduced  RBL.  For  Pope,  with  4  aircraft,  1  item’s  level  reduced  by  2  and  5 
items  reduced  by  1  (for  which  2  of  the  5  levels  were  reduced  from  1  to  0).  Pope  would 
experience  1 .99  more  expected  backorders  from  not  updating  the  demand  data. 

Overall  for  both  bases,  not  updating  the  demand  data  affected  only  2  to  8  percent  of  the  levels. 
For  example,  for  the  Pope  case  with  4  aircraft  transferring,  2.2%  (0.4%  plus  1 .8%)  of  the  levels 
changed.  For  Shaw,  with  more  aircraft  and  therefore  more  demand,  the  results  show  the  loss  of 
one  quarter’s  demand  data  also  had  few  base  levels  affected.  We  conclude  there  is  relatively 
little  impact  from  not  updating  the  demand  data  every  quarter.  So  Option  2,  transferring  demand 
data  at  the  end  of  the  contingency  or  annually,  will  not  have  a  significant  effect  on  home  base 
levels. 

Although  we  show  there  is  not  much  impact  on  the  home  base  levels,  the  Supply  Wartime  Group 
selected  the  more  accurate  (but  more  complicated)  method  to  transfer  the  demand  data  back  to 
the  home  base  upon  the  return  of  the  weapon  system. 
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APPENDIX  C 


ACCL73  Enhancements 


The  ACCL73  is  the  only  program  currently  available  to  transfer  demand  data  from  the 
contingency  site  to  the  home  station.  Although  it  does  a  thorough  job,  some  enhancements 
would  greatly  simplify  the  process. 

Currently,  the  L73  produces  the  same  files  each  time  it  is  processed.  If  multiple  SRDs  or 
organization  codes  are  to  be  transferred,  great  care  must  be  taken  to  copy  the  data  to  safety  files 
before  processing  the  next  SRD/organization  code.  As  seen  in  Figure  C-l  below,  the  same  file 
name  is  used  regardless  of  the  input  parameters  to  the  L73.  If  the  input  parameters  are  used  for 
dynamic  file  allocation  it  would  negate  the  need  for  immediate  backups  (to  process  multiple 
SRD/org  codes)  and  the  data  would  be  recognizable  by  the  filename.  The  parameter  used  in 
Figure  C-l  (SRD=ACK,  org  code  =  123)  will  generate  the  same  files  as  a  subsequent  run  of  the 
L73  with  a  different  parameter  (SRD  of  ABA  and  an  org  code  of  350). 


L73:  SEQUENCE 

OPEN  OUTPUT  DISK-3  USING  TGV0*L73-DATA' ; 
OPEN  OUTPUT  DISK-2  USING  TGV0*L73-FCL' ; 
OPEN  OUTPUT  DISK-1  USING  TGV0*L73-FRR' ; 

1 999275 1 999364ACKA50 1 123  (L73  Parameter) 


Figure  C-l,  Current  L73  Files 


Dynamic  file  allocation  would  create  a  file  name  based  upon  the  input  parameters.  Figure  C-2 
displays  some  SURGE  code  to  dynamically  create  a  file  name  of  “1GV0*L73FCLACK123”  for 
the  parameter  listed  in  Figure  C-l  above.  Using  the  same  example  as  in  the  previous  paragraph, 
a  subsequent  run  with  an  SRD  of  ABA  and  an  org  code  of  350  would  create  the  file  name 
“1GV0*L73FCLABA350”  —  and  it  doesn’t  require  a  file  backup  to  process  multiple  SRD/org 
codes. 


MOVE  ‘1GV0*L73FCL’  &  $READ$-RCD[15,17]  & 

$  RE  ADS-RCD  [22,24]  TO  FCL-INPUTFILE  ; 
OPEN  INPUT  DISK-2  USING  FCL-INPUTFILE  ; 


Figure  C-2,  Proposed  L73  Files 
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A  final  enhancement  to  help  reduce  human  error  would  be  creating  the  FCL  and  FRR  files  to 
subtract  the  demands  being  transferred  to  the  home  base.  Instead  of  copying  off  the  FCL  and 
FRR  files  and  altering  the  images,  the  L73  could  create  the  additional  files  for  (SBSS) 
contingency  processing  (possible  file  names  could  be  1GVO*FCL-<SRD><ORG-CODE>  and 
1 GV  0  *FRR-<SRD><ORG-CODE>) . 

These  two  enhancements,  dynamic  file  naming  and  creating  the  files  for  contingency  processing, 
would  reduce  human  intervention  and  greatly  simplify  the  process.  The  files  would  be  easier  to 
identify  and  reduce  the  steps  necessary  for  contingency  personnel. 
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